\section{Conclusions and future work}
\label{sec-conclusions}

We have presented a technique for inlining local functions that uses
local graph rewriting techniques.  We have proved our technique to be
correct in that it preserves the semantics of the original program,
and it is guaranteed to terminate.

Although our iterative technique can be stopped at any point, thus
giving us \emph{partial inlining}, there are some practical aspects of
such partial inlining that still need to be investigated:

\begin{itemize}
\item When the inlining is not complete, the called function has
  multiple entry points.  Many optimization techniques described in
  the literature assume that a function has a single entry point.  We
  plan to investigate the consequences of such multiple entry points
  on the optimization techniques that we have already implemented, as
  well as on any optimization techniques that we plan to incorporate
  in the future.
\item In our intermediate code, we treat multiple values with an
  unknown number of values as a special type of datum.  It is special
  in that it must store an arbitrary number (unknown at compile time)
  of values.  During the execution of our inlining procedure, such a
  datum may become part of the mapping between variables of the called
  function and the calling function.  When the inlining procedure
  continues until termination, such a datum will be handled in the
  calling function in the same way that it is handled in the called
  function.  However, if the inlining procedure is stopped with such a
  datum in the mapping, we would somehow need to transmit it as an
  argument to the called function.  Doing so may require costly
  allocation of temporary memory and costly tests for the number of
  values that would not be required when the procedure continues until
  termination.  However, it is rare that code needs to store
  intermediate multiple values.  It only happens in a few cases such
  as when \texttt{multiple-value-prog1} is used.  Therefore, one
  solution to this problem is to avoid inlining in this case.  Another
  possible solution is to let the inlining procedure continue until
  termination for these cases.
\end{itemize}

As presented in this paper, our technique handles only functions with
very simple lambda lists.  It is probably not worth the effort to
attempt to inline functions with lambda lists containing keyword
arguments, but it might be useful to be able to handle optional
arguments.  We intend to generalize our technique to such lambda lists.

We have implemented the technique described in this paper, but have
yet to implement a decision procedure for determining whether this
technique could and should be applied.  The details of this decision
procedure are currently being investigated.
